在 Day 1，我先介紹了自己，也說明為什麼想挑戰這次 iThome 鐵人賽。
從今天開始，我想正式把主線帶到 PawPal 這個專案。
這 30 天的文章，不會只是單純整理 JavaScript 語法，也不會只是把專案功能一個一個列出來。
我更想做的是，透過 PawPal 這個真實團隊專案，回頭整理自己在前端學習、團隊協作、功能開發、Debug 和部署過程中，到底經歷了什麼。
但在真正開始介紹功能之前，我想先回到最一開始。
PawPal 這個專案，不是老師直接指定的題目。
它是我們團隊成員各自提出想法、整理架構，再一起討論和投票後，才決定出來的方向。
這對我來說，也是第一次真正感受到：
原來一個專案在開始寫程式之前，就已經有很多事情要先想清楚。
一開始進入團隊專案時，我們不是直接拿到一個固定題目，然後照著做。
而是每個組員都可以提出自己的想法。
大家會先把自己的主題、功能方向或架構圖整理出來，接著給大家一天的時間去研究其他組員的想法。
最後，再透過投票的方式決定要做哪一個專案。
這個過程和以前課堂練習很不一樣。
以前的練習通常是老師已經把題目準備好，我只需要照著需求去完成。
但這一次，我們要先自己思考：
這個網站要解決什麼問題？
使用者是誰？
需要哪些功能？
哪些功能真的有必要？
哪些功能只是想像起來很酷，但實作上可能很困難？
這些問題，都是在還沒開始寫程式之前，就必須先面對的。
其實在一開始討論專案時，我也有提出自己的想法。
我當時提出的方向叫做 Workshop。
它比較像是一個遠端協作與線上會議時使用的互動畫布工具。
我的想法是，很多人在遠端開會時，常常會遇到一個問題：大家腦中有很多想法，但如果只是用嘴巴討論，很容易講過就忘，也不一定能把想法整理清楚。
所以 Workshop 想解決的，是讓遠端討論不只是單純開會，而是可以透過畫布、視覺化工具和互動元件，把討論內容更具體地呈現出來。
在我原本的規劃裡，Workshop 會包含即時同步、白板畫布、便利貼、投票系統、時間倒數、議程清單、AI 協助整理內容、即時聊天室，以及整體視覺體驗等功能。
它和 PawPal 是完全不同的方向。
後來團隊最後決定的方向是 PawPal。
老實說，一開始聽到 PawPal 這個題目時，我其實沒有馬上被說服。
因為我原本提出的是 Workshop，和 PawPal 是完全不同的方向，所以剛開始一定會有一點落差感。
我會先想：
這個題目真的適合嗎？
它的功能會不會太大？
我們真的做得出來嗎？
它和我原本想做的方向差在哪裡？
但後來更深入了解 PawPal 的架構和功能後，我慢慢發現，它其實蠻吸引我的。
PawPal 一開始參考的概念，有點像人類使用的「健保快易通」。
只是這一次，對象換成了毛小孩。
剛好我們組員大多都是飼主，所以大家都能從自己的生活經驗裡提出一些真實痛點。
例如寵物資料要怎麼整理、看診紀錄要怎麼保存、醫院資訊要去哪裡找、日常照護提醒要怎麼安排。
這些問題不是憑空想像，而是身為飼主真的可能會遇到的狀況。
也因為這樣，我開始覺得 PawPal 不只是普通的寵物網站。
它比較像是一個想把飼主需求整合起來的工具。
而且更重要的是，這是一個我自己也會想親自使用的網站。
當我開始有這種感覺時，我就比較能理解為什麼大家最後會選擇 PawPal。
雖然開始覺得 PawPal 很有趣，但壓力也是真的很大。
因為這是我第一次參與真正的團隊專案。
以前寫課堂練習時，做不出來或寫不好，影響的大多是自己。
但團隊專案不一樣。
我的進度，會影響到其他人的進度。
我的功能，可能會接到別人的功能。
我的程式碼，也可能會被組員看到、被討論、被修改。
這讓我一開始很緊張。
我會擔心自己跟不上專案進度，也會擔心自己拖累大家。
但同時，我也很想挑戰看看。
我想知道，自己到底能不能跟上大家的腳步。
也想知道，前面那些學得很挫折的東西，到了真正專案裡，會不會開始變得比較有感覺。
這種心情其實很矛盾。
一方面很害怕，另一方面又很期待。
我們課程主要以前端為主，但也有帶到一點點後端。
所以一開始大家的想法是，先把前端畫面和功能做起來，後續再慢慢分配後端相關工作。
在專案前期，票主要是由組長先開。
組長會把需要完成的任務整理出來，接著大家再依照自己的狀況去認領。
到了後期，因為組長的帶領和前期流程慢慢建立起來，大家也開始接續開票。
也就是說，當一個功能前面已經做出一些基礎後，後續需要延伸、修正或串接的部分，就會再開新的票繼續完成。
這對我來說，也是第一次比較正式地接觸團隊開發的流程。
以前我對「開票」的理解很模糊。
但真正做專案後才發現，開票不只是把事情寫下來而已。
它其實是在幫團隊拆解工作。
一個大功能如果沒有拆成比較小的任務，大家就很難知道自己現在要做什麼，也很難知道整個專案進度到哪裡。
第一次團隊專案裡，讓我最不習慣的其中一件事，就是 Code Review。
因為我自己的程式碼，有時候都需要花很長的時間才能理解。
更不用說要去看懂其他組員寫的程式碼。
每次要幫組員 Code Review 時，我都會覺得難度很高。
我會想：
我真的看得懂這段在做什麼嗎？
我有辦法判斷這樣寫有沒有問題嗎？
如果我問了很基本的問題，會不會讓大家覺得我跟不上？
這些想法一開始都會讓我有壓力。
但後來我也慢慢發現，Code Review 不一定是要一開始就像很厲害的工程師一樣，馬上指出很多問題。
對新手來說，它也可以是一個理解專案的過程。
就算只是看懂別人在做什麼、問清楚某段邏輯為什麼這樣寫，其實也是在參與團隊協作。
這個部分後面我也會再用一篇文章好好整理，因為 Code Review 對我來說，不只是檢查程式碼，也是第一次學著用團隊的角度看專案。
PawPal 和以前課堂練習最大的不同，就是它不是一個已經被切好的題目。
課堂上，老師通常會先講一個觀念，接著給一個練習。
那時候我常常是照著題目做，但其實不一定能真正體會：
為什麼這段程式要這樣寫？
這個功能在真實網站裡會用在哪裡？
可是到了 PawPal，感覺完全不一樣。
我們不是一開始就有完整答案。
而是要從零開始想：
這個功能要解決什麼問題？
使用者會怎麼操作？
畫面要怎麼呈現？
資料要從哪裡來？
前端和後端要怎麼串起來？
不同組員做的功能最後要怎麼整合？
這些問題，讓我第一次真正感受到專案和練習題的差別。
練習題比較像是在學某一段語法或觀念。
但專案是在把很多觀念串起來，變成一個真的可以被使用的網站。
也因為這樣，我才開始慢慢理解：
寫程式不是只把語法寫出來。
更重要的是，讓功能能夠解決問題，並且和其他功能一起運作。
PawPal 不是一開始就完美的專案。
它也不是某個人突然想出來，然後大家直接照做的題目。
它是團隊成員從自己的想法、飼主經驗、使用需求裡，一步一步討論出來的結果。
對我來說，PawPal 不只是一個課程專案。
它是我第一次真正參與一個從想法、分工、開票、實作，到最後整合成網站的團隊開發過程。
也因為有 PawPal，我才開始感受到，前端開發不只是把畫面切出來，也不只是把語法寫對。
它還包含需求理解、功能規劃、團隊溝通、版本控制、資料串接，還有很多一開始在課堂上很難真正體會的事情。
這也是為什麼我會選擇用 PawPal 作為這 30 天的主線。
因為它剛好包含了我在前端學習過程中最重要的幾個部分：
學習語法、理解功能、和組員協作、處理 Git、串接 API、面對 Bug、完成部署，最後再回頭整理自己到底學到了什麼。
所以接下來的文章，我會從 PawPal 的每一次功能開發、每一次卡關、每一次協作經驗開始，慢慢把背後的技術觀念整理出來。
今天，我整理了 PawPal 這個專案是怎麼出現的，也回顧了自己第一次加入團隊專案時的感受。
當專案方向確定後，接下來就要真的開始分工與協作。
而多人協作第一個讓我感受到壓力的，就是 Git 和 GitHub。
下一篇會聊聊：
第一次多人協作，我才知道 Git 沒有想像中簡單。
iThome鐵人賽
看影片追技術